[SUGGESTION] zwavejs2matter (ZWave-to-Matter, formerly Project CHIP) gateway/bridge as a subproject to be an alternative to ZWave-to-MQTT?

[Hedda]

What are your thoughts on expanding zwavejs2mqtt scope to also support "Matter" output as an optional alternative to MQTT output?

Matter (formerly "Project CHIP") is an application layer made as an application connectivity protocol is designed as an alternative to MQTT.

For reference, yesterday "Project Connected Home over IP" (a.k.a. "Project CHIP") was renamed to "Matter", and the Zigbee Alliance was renamed o "Connectivity Standards Alliance" (or "CSA" for short) to make it clearer that is governing more IoT standards than just the Zigbee standard, (those standards include; Zigbee, Smart Energy, Green Power, JupiterMesh, Dotdot, and now also Matter).

https://www.businesswire.com/news/home/20210511005928/en/The-Connectivity-Standards-Alliance-Unveils-Matter-Formerly-Known-as-Project-CHIP

Since the Z-Wave network media specification is still out-of-scope for the "Matter" project I think it could be a great idea to have a "Z-Wave to Matter" server application that would act as a "Z-Wave to Matter" gateway/bridge.

It is beyond my skills but would like to suggest you consider "zwavejs2matter" (Z-Wave to Matter) gateway/bridge as a subproject to zwavejs2matter or as an official fork of the project.

Low-power devices that natively supports the "Matter" standard will be based on Thread and should not start to arrive until later this year and I guess most people who already have a large setup with Z-Wave (or Zigbee) will not want to start over or switch to using devices that use an other mesh networking standard and thus those people who still want to use Z-Wave devices but want to utilize Matter will need "Z-Wave to Matter" gateways/bridges (and "Zigbee to Matter" gateways/bridges).

The new official website for Matter is buildwithmatter.com (as the old website www.connectedhomeip.com is no longer online) and the project's source code git repositories on GitHub is still active at https://github.com/project-chip/ and Connectivity Standards Alliance new website https://csa-iot.org/ still redirect to https://zigbeealliance.org/about/

https://github.com/project-chip/connectedhomeip/blob/master/README.md

References:

https://github.com/project-chip/connectedhomeip

https://github.com/project-chip/

https://zigbeealliance.org/news_and_articles/chip-is-now-matter/

https://zigbeealliance.org/news_and_articles/connectivity-standards-alliance/

Connectivity Standards Alliance new website https://csa-iot.org/ still redirect to https://zigbeealliance.org/about/

PS: Matter is likely to become a big deal in the long run as alliance members poised to be early adopters of Matter include: Amazon, ASSA ABLOY, Comcast, Espressif Systems, Eve Systems, Google, Grundfos Holding A/S, Huawei, Infineon Technologies, LEEDARSON, Legrand, Nanoleaf, Nordic Semiconductor, NXP Semiconductors, Qorvo, Resideo, Schlage, Schneider Electric, Philips Hue / Signify, Silicon Labs, Samsung SmartThings, Somfy, STMicroelectronics, Texas Instruments, Tuya Smart, Ubisys, Wulian, and Zumtobel Group.

[robertsLando]

It's not very clear to me how I should translate datas from zjs to matter and vice versa. Is there a nodejs package to use 'Matter protocol' ?

[Hedda]

It's not very clear to me how I should translate datas from zjs to matter and vice versa. Is there a nodejs package to use 'Matter protocol' ?

Sorry but I do not think that there is a nodejs package for the Matter/CHIP protocol as of yet, (however note when searching for such project it will be better to use keywords "Project CHIP" or "Connected Home over IP" as all projects for it have not been rebranded to "Matter" yet and regardless that new name makes it hard to search for without context).

https://github.com/project-chip/

https://github.com/project-chip/connectedhomeip/blob/master/README.md

Maybe base it on "ZAP" from the same project as it's a nodejs ZCL (Zigbee Cluster Library) configuration tool and generator?

At least ZAP looks to be a node.js application?

https://github.com/project-chip/zap

By the way, there looks to be a BLE to CHIP bridge example here as a proof-of-concept, but it is written in C++ code:

https://github.com/project-chip/connectedhomeip/blob/master/examples/bridge-app/linux/README.md

https://github.com/project-chip/connectedhomeip/tree/master/examples/bridge-app

https://github.com/project-chip/connectedhomeip/tree/master/examples/bridge-app/linux

https://github.com/project-chip/connectedhomeip/tree/master/examples/bridge-app/bridge-common

FYI, Matter/CHIP was actually created with inspiration from Zigbee as its application layer is based on Zigbee Cluster Library (ZCL) specs as Matter/CHIP uses Zigbee Cluster Library protocol which defines common means for applications to communicate. See ex:

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/connected-home-over-ip-sneak-peek-of-early-development-on-nrf52840

[Hedda]

Best is probably to try asking at https://github.com/project-chip/connectedhomeip/issues as others seem to post questions there are and guidelines do not say https://github.com/project-chip/connectedhomeip/blob/master/CONTRIBUTING.md

[robertsLando]

Actually I have no time to invest in a new project, I prefer to focus on z2m for now, also I don't see so much support on nodejs side and I would like to avoid any kind of native nodejs module, my experience with OZW has been terrible

[ivdimitro]

Hi, I think this is the wrong approach. Both zwave and matter are both transmission protocols to communicate with IoT devices. Transforming the model matter --> zwave --> MQTT --> HA doesn't make much sense.
A more reasonable approach will be matter --> MQTT --> HA.
The MQTT hop is optional.

[Hedda]

I thought most logical would be to entirely skip the MQTT hop in that model and only transform Z-Wave to Matter:

Z-Wave --> Matter

Hence the original suggestion of a "zwavejs2matter" (ZWave-to-Matter) subproject.

That is, for zwavejs2mqtt to optionally support Matter output and an optional alternative to MQTT output.

Then there could be a completely separate project that would only transform Matter to MQTT.

[Hedda]

Both zwave and matter are both transmission protocols to communicate with IoT devices.

FYI, Matter is not a transport protocol. (Matter relies on Thread, WiFi, and/or Bluetooth as the transport layer).

Matter is at the application layer as an application connectivity protocol. So it is in fact an alternative to MQTT.

Architecture Overview

The Project, as illustrated above, defines the application layer that will be
deployed on devices and controllers as well as the supported IPv6-based networks
to help achieve our interoperability architectural goal. Project CHIP will
initially support Wi-Fi and Thread for core, operational communications and
Bluetooth Low Energy (BLE) to simplify device commissioning and setup.

The Application Layer can be further broken down seven main components:

1. Application: High order business logic of a device. For example, an
   application that is focused on lighting might contain logic to handle turning
   on/off the bulb as well its color characteristics.

2. Data Model: Data primitives that help describe the various
   functionalities of the devices. The Application operates on these data
   structures when there is intent to interact with the device.

3. Interaction Model: Represents a set of actions that can be performed on
   the devices to interact with it. For example, reading or writing attributes
   on a device would correspond to interactions with the devices. These actions
   operate on the structures defined by the data model.

4. Action Framing: Once an action is constructed using the Interaction
   Model, it is framed into a prescriptive packed binary format to enable being
   well represented on the “wire”.

5. Security: An encoded action frame is then sent down to the Security Layer
   to encrypt and sign the payload to ensure that data is secured and
   authenticated by both sender and receiver of a packet.

6. Message Framing & Routing: With an interaction encrypted and signed, the
   Message Layer constructs the payload format with required and optional header
   fields; which specify properties of the message as well some routing
   information.

7. IP Framing & Transport Management: After the final payload has been
   constructed, it is sent to the underlying transport protocol for IP
   management of the data.