Streamline the API to make it more accessible, less complicated

[andyearnshaw]

I know this project is in its early days and, so far, it looks promising. However, it seems somewhat overly complex for my use case and I'd love to see better abstractions, use of defaults and an intuitive API to make things more developer-friendly.

I'm not sure what the majority use case will be for this library but, as a developer with experience in TypeScript/JavaScript I'm looking at using it in the near future to manually bridge some non-matter devices to my Google Home setup. I may potentially branch out into building virtual devices that trigger things on my computer or router, too.

Looking at src/Device.ts, it seems that there's a lot of configuration and boilerplate to add a simple on/off device. I think it would be great to look at patterns in established JavaScript libraries and see if a simple virtual on/off switch could be streamlined into something like this:

import { createDevice, DeviceType } from "node-matter";
import { 
  privateKey,
  deviceCertificate,
  deviceIntermediateCertificate,
  certificateDeclaration
} from "./config"

const myDevice = createDevice(DeviceType.GENERIC_SWITCH, {
  name: "Matter test device",
  vendorName: "node-matter",
  vendorId: 0xFFF1,
  productName: "My switch",
  productId: 0x8001,
 
  credentials: { 
    privateKey,
    deviceCertificate,
    deviceIntermediateCertificate,
    certificateDeclaration
  },
})
  .on("switchon", () => console.log("Switch is on"))
  .on("switchoff", () => console.log("Switch is off"))
  .udpListen(5540);

console.log(`QR Code URL: https://project-chip.github.io/connectedhomeip/qrcode.html?data=${myDevice.getQrPairingCode()}`);
console.log(`Manual pairing code: ${myDevice.getManualPairingCode()}`);

Things like protocols, broadcasters, cluster servers, passcodes, etc can all be abstracted away unless the developer needs finer control, or to add a custom/future device that has not been implemented in this library yet.

[Apollon77]

I converted the issue into a discussion

Yes you are right that tjis will come and I personally will also primarily want to provide devcies, so Once we have a working thing (at all) it is the next step to streamline this

[mfucci]

@andyearnshaw Thanks for looking at node-matter for your projects!

I think all your use cases is what we have in mind for node-matter.

As you said, node-matter is still at his early days and unfortunately too many low-level things are not working so we haven't had the chance to define / build a nice API to use it.

Here is my best vision for an API at this point:

import { Node, DeviceSwitch } from "node-matter";

const myNode = new Node({ productName: "Matter switch" })
   .addDevice(new DeviceSwitch({
       on: () => console.log("Switch is on"),
       off: () => console.log("Switch is off"),
   });
myNode.start();

console.log(myNode.getTextQrCode());
console.log(`QR Code URL: https://project-chip.github.io/connectedhomeip/qrcode.html?data=${myDevice.getQrPairingCodeData()}`);
console.log(`Manual pairing code: ${myDevice.getManualPairingCode()}`);

MatterNode takes a NodeOptions object with all fields optional.

• vendorName: default is "node-matter"
• vendorId: default is one of few IDs available for development
• productName: default is string representation of product ID
• productId: default is a random number
• privateKey, deviceCertificate, deviceIntermediateCertificate, certificateDeclaration: default are auto-generated (nothing really interesting in those...)

DeviceSwitch takes a SwitchOptions object with all fields optional:

• on: callback to turn on
• off: callback to turn off

What is missing in the current code to achieve this:

• the "device" level abstraction: a device is a collection of clusters and defined in the specs.
• the logic to auto-generate of all the certificates
• the code to expose this interface

What are the low-level blocks missing to be able to make it functional:

• compatibility with Android / iOs: this is where I spent my efforts right. I am nearly there with iOs and at the beginning with Android
• multi-fabric support: somehow iOs is provisioning 3 fabrics which is not really supported yet

What do you think of the APIs above?
Are you willing to help us implement it?
If so you can start be creating the code to expose this interface and I can help you with the wiring.
Hopefully in parallel I will get Android / iOs working in the next few weeks.

Thanks!

• Marco